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Hybrid device and person based authorized domain architecture 



The invention relates to a method of generating an Authorized Domain. The 
invention further relates to a system for generating an Authorized Domain. Further, the 
invention relates to a computer readable medium having stored thereon instructions for 
causing one or more processing units to execute the method according to the invention. 

5 

Recent developments in content distribution technologies (i.e. the Internet and 
removable media) make it much easier to exchange content than ever before. The rapid 
adoption by consumers shows that such technologies really address their needs. A side effect 

10 is that they also enable easy illegal copying and distribution of content. The content industry 
sees this latter development as a threat to their business. Therefore in recent years, the 
amount of content protection systems is growing in a rapid pace. Some of these systems only 
protect the content against illegal copying, while others are also prohibiting the user to get 
access to the content. The first category is called Copy Protection (CP) systems. CP systems 

15 have traditionally been the main focus for consumer electronics (CE) devices, as this type of 
content protection is thought to be cheaply implemented and does not need bi-directional 
interaction with the content provider. Some examples are the Content Scrambling System 
(CSS), the protection system of DVD ROM discs and DTCP (a protection system for IEEE 
1394 connections). 

20 The second category is known under several names. In the broadcast world, 

systems of this category are generally known as conditional access (CA) systems, while in 
the Internet world they are generally known as Digital Rights Management (DRM) systems. 

A home network can be defined as a set of devices that are interconnected 
using some kind of network technology (e.g. Ethernet, IEEE 1394, BlueTooth, 802.1 lb, 

25 802.1 lg, etc.). Although network technology allows the different devices to communicate, 
this is not enough to allow devices to intemperate. To be able to do this, devices need to be 
able to discover and address the functions present in the other devices in the network. Such 
interoperability is provided by home networking middleware. Examples of home networking 
middleware are Jini, HAVi, UPnP, AVC. 



WO 2005/010879 



PCT7IB2004/051226 



PHNL030926 PCT/IB2004/051 226 

2 

The concept of Authorized Domains (ADs) tries to find a solution to both 
serve the interests of the content owners (that want protection of their copyrights) and the 
content consumers (that want unrestricted use of the content). The basic principle is to have a 
controlled network environment in which content can be used relatively freely as long as it 

5 does not cross the border of the authorized domain. Typically, authorized domains are 

centered around the home environment, also referred to as home networks. Of course, other 
scenarios are also possible. A user could for example take a portable device for audio and/or 
video with a limited amount of content with him on a trip, and use it in his hotel room to 
access or download additional content stored on his personal audio and/or video system at 

10 home. Even though the portable device is outside the home network, it is a part of the user's 
authorized domain. In this way, an Authorized Domain (AD) is a system that allows access to 
content by devices in the domain, but not by any others. 

For a more extensive introduction to the use of an Authorized Domain, etc., 
see S.A.F.A. van den Heuvel, W. Jonker, F.L.A J. Kamperman, P.J. Lenoir, Secure Content 

15 Management in Authorised Domains, Philips Research, The Netherlands, IBC 2002 
conference publication, pages 467-474, held at 12-16 September 2002. 

Various proposals exist that implement the concept of authorized domains to 

some extent. 

One type of previous solutions include device based Authorized Domains 
20 (ADs). Examples of such systems are SmartRight (Thomson Multimedia), xCP, and 

NetDRM (Matshushita). A further example of a device based AD is e.g. given in European 
patent application serial number 02076998.0 (attorney docket PHNL020455) by the same 
applicant 

In typical device based ADs, the domain is formed by a specific set of devices 
25 and content. Only the specific set of devices of the domain is allowed to access, use, etc. the 
content of that domain. There is not made any distinction of the various users of the specific 
set of devices. 

A drawback of device based AD systems is that they typically do not provide 
the typical flexibility that a user wants or need, since users are restricted to a particular and 
30 limited set of devices. In this way, a user is not allowed to exercise the rights that the user has 
obtained anytime and anywhere he chooses. For example, if a user is visiting a friend's house 
he is not able to access his legally purchased content on the friend's devices as these devices 
would not typically be part of the particular and limited set of devices forming the domain 
comprising the user's content. 
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Another type of previous solutions are person based Authorized Domains, 
where the domain is based on persons instead of devices as was the case for device based 
ADs. An example of such a system is e.g. described in European patent application serial 
number 02079390.7 (attorney docket PHNL021063) by the same applicant in which content 
5 is coupled to persons which then are grouped into a domain. 

In a typical person based AD access to content bound to that AD is allowed by 
only a specific and limited set of users, but e.g. using any compliant device. Person based 
Authorized Domains typically offer easier domain management compared to device based 
ADs. 

10 However, person based systems require person identification which is not 

always convenient or preferred by users. Further, a visitor to your home may want to access 
your content. As he does not have a person id device for that domain it is not possible for him 
to access content. It would be preferred if devices in the home belonging to the domain could 
enable access of domain content by the visitor. 

15 Therefore there is a need for a hybrid person and device based authorized 

domain having the individual advantages of each system. 



It is an object of the invention to provide a method and corresponding system 
20 for providing an Authorized Domain structure based on both persons and devices. An 
additional object is to provide a method and system solving the above-mentioned 
shortcomings of prior art. A further object is to provide this in a simple, flexible and efficient 
way. 

These objects, among others, are achieved by a method (and corresponding 
25 system) generating an Authorized Domain (AD), the method comprising the steps of 

selecting a domain identifier uniquely identifying the Authorized Domain, binding at least 
one user to the domain identifier, and binding at least one device to the domain identifier, and 
thereby obtaining a number of devices and a number of persons that is authorized to access a 
content item of said Authorized Domain. 
30 Hereby, a simple and efficient way of grouping devices and persons to an AD 

is obtained. Further, a hybrid device and person based Authorized Domain is provided. In 
this way, access is enabled to a content item of an authorized domain by a user operating a 
device either by verifying that the content item and the user is linked the same domain or by 
verifying that the device and the content item is linked to the same domain. Thereby, 
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enhanced flexibility for one or more users when accessing content in an authorized domain is 
obtained while security of the content is still maintained. This is further done in a simple, 
secure and reliable way. 

In one embodiment, the method further comprises the step of binding at least 
5 one content item to the Authorized Domain given by the domain identifier. 

In one embodiment, the step of binding at least one user to the domain 
identifier comprises: obtaining or generating a Domain Users List (DUC) comprising the 
domain identifier and a unique identifier for a user thereby defining that the user is bound to 
the Authorized Domain and/or the step of binding at least one device to the domain identifier 
10 comprises: obtaining or generating a Domain Devices List comprising the domain identifier 
and a unique identifier for a device thereby defining that the device is bound to the domain. 

In one embodiment, the step of binding at least one content item to the 
Authorized Domain (AD) comprises: 

- binding a content item to a User Right, where said User Right is bound to a user 
1 5 bound to the Authorized Domain, and/or 

- binding a content item to a Device Right, where said Device Right is bound to a 
device bound to the Authorized Domain. 

In one embodiment, the step of binding at least one content item to the 
Authorized Domain comprises: 
20 - binding a content item to a Domain Right, where said Domain Right is bound to the 

Authorized Domain. 

In one embodiment, the User Right or the Device Right or the Domain Rights 
comprises rights data representing which rights exists in relation to the at least one content 
item bound to the User Right or the Device Right or the Domain Rights. 
25 In one embodiment, the method further comprises the step of controlling 

access to a given content item bound to the Authorized Domain by a given device being 
operated by a given user, the step comprising: 

- checking if the given user is bound to the same Authorized Domain as the given 
content item, or 

30 - checking if the given device is bound to the same Authorized Domain as the given 

content item, 

and allowing access for the given user via the given device and/or other 
devices to the content item if the given user is bound to the same Authorized Domain, 
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or allowing access for the given user and/or other users via the given device to 
the content item if the given device is part of the same Authorized Domain. 

In one embodiment, the method further comprises the step of controlling 
access to a given content item, being bound to the Authorized Domain and having a unique 
5 content identifier, by a given device being operated by a given user comprising: 

- checking if the Domain Devices List of the Authorized Domain comprises an 
identifier of the given device, thereby checking if the given device is bound to the 
same Authorized Domain as the content item, and/or 

- checking if the Domain User List of the Authorized Domain comprises an identifier 
10 of the given user thereby checking if the given user is bound to the same Authorized 

Domain as the content item, 

- and allowing access to the given content item by the given device for any user if the 
given device is bound to the same Authorized Domain as the content item being 
accessed, and/or 

15 - allowing access to the given content item by any device including the given device for 

the given user if the given user is bound to the same Authorized Domain as the 
content item being accessed. 

In one embodiment, the step of controlling access of a given content item 
further comprises: 

20 - checking that the User Right for the given content item specifies that the given user 

has the right to access the given content item and only allowing access to the given 
content item in the affirmative. 

In one embodiment, every content item is encrypted and that a content right is 
bound to each content item and to a User Right or a Device Rights or a Domain Rights, and 
25 that the content right of a given content item comprises an decryption key for decrypting the 
given content item. 

In one embodiment, 

- the Domain Users List is implemented as or included in a Domain Users Certificate, 
and/or 

30 - the Domain Devices List is implemented as or included in a Domain Devices 

Certificate, and/or 

- the User Right is implemented as or included in a User Right Certificate, and/or 

- the Device Right is implemented as or included in a Device Right Certificate, and/or 

- the Domain Rights is implemented/included in a Domain Rights Certificate. 



WO 2005/010879 



PCT/TO2004/051226 



PHNL030926 PCT/IB2004/051 226 

6 

Advantageous embodiments of the system according to the present invention 
are defined in the sub-claims described in detail in the following. The embodiments of 
system correspond to the embodiments of the method and have the same advantages for the 
same reasons. 

5 Further, the invention also relates to a computer readable medium having 

stored thereon instructions for causing one or more processing units to execute the method 
according to the present invention. 

10 These and other aspects of the invention will be apparent from and elucidated 

with reference to the illustrative embodiments shown in the drawings, in which: 

Figure 1 schematically illustrates binding of persons, devices, user rights, and 
content in an authorized domain (AD) according to the present invention; 

Figure 2 schematically illustrates binding of persons, devices, user rights and 
15 content in an authorized domain (AD) according to an alternative embodiment of the present 
invention; 

Figure 3 schematically illustrate the elements of a Domain Devices Certificate 
(DDC) and of a Domain Users Certificate (DUC); 

Figure 4a illustrates an exemplary (partial) data structure of a content 
20 container, a content right (CR) and a user right certificate (URC) according to the 
embodiment of the present invention shown in Figure 1; 

Figure 4b illustrates an exemplary (partial) data structure of a content 
container, a content right (CR) and a Domain Rights Certificate (DRC) according to the 
embodiment of the present invention shown in Figure 2; 
25 Figure 5 schematically illustrate an exemplary system comprising devices and 

persons forming an authorized domain (AD). 

Throughout the figures, same reference numerals indicate similar or 
corresponding features. Some of the features indicated in the drawings are typically 
implemented in software, and as such represent software entities, such as software modules 
30 or objects. 

Figure 1 schematically illustrates binding of persons, devices, user rights and 
content in an authorized domain (AD) according to the present invention. Shown are an 
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authorized domain (100) according to the present invention where a number of devices Dl, 
D2, D3, . . ., DM (where M is equal to or larger than 1), a number of content items CI, C2, 
C3, . . ., CN2 (where N2 is equal to or larger than 1) and a number of persons/users PI , P2, P3, 
.. PNi (where Ni is equal to or larger than 1) is bound to the AD according to an 

5 embodiment of the present invention. The devices, persons, and content items have been 

bound to the domain (100), as will be explained later. Also shown are one or more user rights 
(URC1, ... URCN2), where preferably one content item is associated with one user right 
certificate specifying which rights a given person (or alternatively a given group of persons 
and/or all persons bound to the domain (100)) have in relation to the specific content item (or 

10 alternatively, several or all content items in the domain (100)). 

For more information on an authorized domain architecture and 
implementation options, the reader is referred to European patent application serial number 
01204668.6 (attorney docket PHNL010880) by the same applicant or European patent 
application serial number 02076998.0 (attorney docket PHNL020455) by the same applicant. 

1 5 European patent application serial number 02076998.0 (attorney docket PHNL020445) more 
specifically describes an implementation in which content and devices are coupled to a 
domain. Additionally, European patent application serial number 02079390.7 (attorney 
docket PHNL021063) by the same applicant describes an implementation in which content is 
coupled to persons which then are grouped into a domain. 

20 Please note that in practice content can only be accessed/used by means of a 

user operating a device. In the following text we assume that devices used in the system are 
compliant and "public" devices. This means that a device will adhere to certain operation 
rules (e.g. will not illegally output content on an unprotected digital interface) and that 
ownership of a device is not important (public). Device compliancy management, i.e. 

25 compliant device identification, renew-ability of devices, and revocation of devices, will be 
assumed to be in place (using known techniques), and will not be considered further here. 

The user right (URC1, ... URCN2) is a single connection, binding, coupling 
etc. between one user and a content right (which is required to decrypt a piece of content). By 
introducing this user right we now have five main entities in our system that could work as 

30 follows: 

- content (CI, C2, C3, CN2): content items are preferably encrypted (there are many 
options, for example with a unique key per content title) and can be anywhere in the 
system; a content item is in this embodiment linked indirectly to a user right 
certificate via a content right, as also explained in connection with Figure 4a. 
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- content right (CR; not shown; see e.g. Figure 4a): contains cryptographic key(s) or 
other suitable protection means to access a certain (encrypted/protected) content item. 
The system is flexible in the sense that content rights can be made unique per content 
title or even unique per specimen (copy) of content Content rights should be only 

5 transferred to compliant devices. A more secure rule is to enforce that content rights 

may be only transferred to compliant devices that are operated by authorized users 
(i.e. users that are authorized to have access to the specific content right by means of 
their user rights). Content rights might also be stored together with the content on for 
example an optical disk. However, content rights must be stored securely since they 
10 contain the content decryption key. 

- user right certificate (URC 1 , . . . URCN 2 ): a certificate or the like issued by the 
content provider that authorizes a person to use a certain content right (CR) 
(belonging to a certain piece of content). User rights can be in principle anywhere in 
the system. Preferably, the user right certificate also comprises rules (e.g. restricted to 

15 viewers 1 8 years or older, or European market only, etc.) of access to a certain 

content item. 

- device (Dl, D2, D3, . . ., DM): a device that is used to play, operate, record, present, 
display, modify, etc. a content item. Additionally, a (compliant) device can also 
preferably identify a user by means of a personalized identification device (e.g. such 

20 as a smart-card, a mobile phone, a biometric sensor, etc.) and collect certificates (e.g. 

from the smartcard, or from other devices) that prove that the user is allowed to use a 
certain content right This content right could be obtained from the smart-card where 
it was stored (if it was stored there), or be obtained (securely transferred) from 
another compliant device on a network. 

25 - user/person (PI, P2, P3, . . PNi): A user is identified by some biometric or 

preferably by a personalized identification device (e.g. a smartcard, mobile phone, a 
mobile phone containing a smartcard or other types of devices that uniquely identifies 
a user) that he/she is wearing, carrying or has access to. A mobile phone comprising a 
smart card or another device having storage means is preferred since it allows users to 

30 carry rights with them (for accessing content on off-line devices). The identification 

device may itself be protected by a biometric authentication mechanism, so that 
anyone other than the legitimate owner cannot use the identification device. A user 
may also be identified using public key technology or zero-knowledge protocols or a 
combination thereof. 
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Preferably, authorized devices are bound to the AD (100) by a certificate. 
Likewise authorized persons/users are preferably also bound to the AD (100) via certificates. 
Content items are, in this particular embodiment, bound to a person by means of a user right 
certificate (URC). This user right certificate enables the use of a corresponding content right 
5 (CR) that preferably contains a cryptographic key for accessing the content, as will be 
explained in greater detail in connection with Figure 4a. A user right certificate (URC) is 
typically linked with one content item, but could also be linked with multiple content items. 
An exemplary partial data structure of a content container (contains a content item), a URC 
and a CR are shown and explained in greater detail in connection with Figure 4a. 
10 Domain certificates are preferably issued by a domain authority. Alternatively, 

compliant devices with domain management capabilities can manage these certificates. 

In the example shown in Figure 1, each content item CI, C2, CN 2 is 
coupled to a user right certificate URC1, URC2, . . ., URC N 2 . URC1 and URC2 are coupled 
to person PI, URC3 coupled to person P2, URC 2 . 2 > URC 2 -i and URC 2 are coupled to person 
1 5 PNi, and URC4-URC 2 . 3 are distributed among person(s) P3-PNm. 

In this way, specific content CI and C2 are coupled to a specific person PI, 
specific content C3 coupled to a specific person P2, specific content CN 2 . 2 , CN 2 .i and CN 2 
are coupled to a specific person PNi, and specific content C4-CN 2 _3 are distributed among 
specific person(s) P3-PNm via their respective URC. 
20 In this shown embodiment, a single content item is only allowed to be coupled 

to a single URC (indirectly via a content right) and thereby a single person. If several users 
needs a copy of the same content item it would in this embodiment be present once for each 
user and treated as different content items, which make rights management simpler. 
Alternatively and just as applicable, a single content item could be coupled to more than one 
25 person, as a CR can be linked to multiple URCs. 

Persons PI, P2, PNi and Domain devices Dl, D2, DM are then 
grouped into forming the authorized domain (100). 

Preferably, the binding, i.e. grouping and coupling, of devices, persons and 
content is according to the present invention done by the use of certificates. Preferably a 
30 Domain Devices Certificate or Domain Devices List (DDC), a Domain Users Certificate or 
Domain Users List (DUC), and a User Right Certificate or User Right List (URC) are used. 
In the following reference is only made to certificates, although it is to be understood that 
such structures may e.g. be implemented as lists or the like instead. 
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The DDC lists the device(s), which are part of the domain (100), e.g. by 
comprising for each device a unique identifier. The DUC lists the user(s), which are part of 
the domain, e.g. by comprising a unique identifier or a (e.g. public) cryptographic key or a 
hash thereof for each user. DUC and DDC are shown an explained in greater detail in 

5 connection with Figure 3. The URC preferably exist for each content item (so in the 

exemplary embodiment of Figure 1 there are N 2 URCs) and indicates which rights the user 
(that the URC is linked to) has (and/or does not have) within the domain (100), and 
optionally a cross domain (X-AD rights), for the given content item linked to the URC. 
Alternatively, an URC coupled to a given user e.g. lists each content item that is coupled to 

10 the given user and what rights the given user has in relation to each coupled content item. 
Alternatively, only a single URC is used specifying the rights for every user, i.e. which 
content item(s) each user has coupled to him/her and what rights the user has (and/or does not 
have). 

In a preferred embodiment, the DDC and DUC are associated with each other 

1 5 by means of a Domain Identifier (DomainJTO) contained in both certificates. In this way, a 
very simple way of linking the user(s) (and thereby the content item(s)) and the device(s) of a 
given domain together (and thereby forming the domain) is obtained. 

If a specific device (e.g. device D3) wants to access a certain piece of content 
(e.g. content CI) it has to be proved or checked, etc. (using the certificates) that the certain 

20 piece of content is coupled to a specific person (e.g. person PI) that is a member of the same 
domain (100) as the specific device. This may e.g. by done by checking that an (unique) 
identifier of the specific device (e.g. device D3) is part of the DDC, that an (unique) identifier 
of the specific person (e.g. person PI) is part of the DUC, that both the DDC and DUC 
comprises the same Domain Identifier (e.g. Domain JD = 4 or DomainJD = 8 byte value 

25 (e.g. generated randomly); not shown), and that the URC for the specific person (e.g. URC1) 
specifies that the specific person has the right to access the certain piece of content (e.g. if it 
is within the validity period of his license or have not been used more than three times, etc.). 
This will be illustrated in greater detail in connection with Figure 4a. Alternatively, the 
Domain ID may instead of being a random number be a reference to a data object e.g. a 

30 domain certificate. 

By having the content items coupled to persons (via URCs) the ownership of 
content is easily reflected. Additionally, it is easier to administer a split of the AD, since by 
splitting the persons the appropriate content items is also split, since the content items are 
linked to persons. 
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Hereby, one or more devices, one or more persons, and at least one content 
item (via a person) are linked together in the domain preferably with the use of certificates or 
alternatively with the use of lists comprising the same described elements as for the 
certificates. It may be possible for the domain to comprise zero persons and/or zero devices 
5 and/or zero content items during some points. E.g. when initially building the domain it may 
comprise zero content items or zero devices bound to the domain, etc. 

In this way, a user that has been verified as belonging to the same domain as 
the content item being accessed may access the specific content using any device. 
Additionally, a user that is using a device that has been verified as belonging to the same 
10 domain as the content item being accessed may access the specific content using that specific 
device. Further all users may access the specific content item on that specific device. 

This gives enhanced flexibility for one or more users when accessing content 
in an AD while security of the content is still maintaining. 

In an alternative embodiment, the content may be bound to the devices of the 
15 domain instead of to the persons of the domain. Instead of a User Right Certificate a Device 
Right Certificate (DevRC) (not shown) is used. The Device Right Certificate (DevRC) would 
then have the same content as the URC with the exception of a Device ID instead of a Person 
ID. The rest is un-changed. 

It is also to be understood that instead of having one list or certificate 
20 comprising users (i.e. the DUC) and one list or certificate comprising devices (i.e. DDC) 
above and in the following other arrangements may also be used. As an alternative, both 
devices and users could be comprised in a single list/certificate. Further, several 
lists/certificates comprising devices and/or several lists/certificates comprising users and/or 
combinations thereof may be used just as well. 
25 Figure 2 schematically illustrates binding of persons, devices, user rights and 

content in an authorized domain (AD) according to an alternative embodiment of the present 
invention. This shown embodiment corresponds to the one shown in Figure 1 with the only 
exception that instead of coupling content items CI, C2, CN2 to persons PI, P2, PNi 
via user right certificates URC1, URC2, URC N 2 , the content items are coupled to the 
30 domain (100) via one or more Domain Rights (DRC). Preferably, one content item is coupled 
to one DRC. In a preferred embodiment the DRC is implemented as a certificate. 

If a specific device (e.g. device D3), in this embodiment, wants to access a 
certain piece of content (e.g. content CI) it has to be proved or checked, etc. (using the 
certificates) that the certain piece of content is coupled to the same domain (100) as the 
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specific device or that a specific person (e.g. person PI) operating the device is a member of 
the domain. This may in this embodiment e.g. be done by checking that an (unique) identifier 
of the specific device is part of the DDC or that an (unique) identifier of the specific person is 
part of the DUC. Further it should be checked that the certain piece of content is coupled to a 

5 DRC that is part of the domain and that the DDC or the DUC comprises the same Domain 
Identifier, and that the DRC for the specific content specifies that a person of the domain has 
the right to access the certain piece of content (e.g. if it is within the validity period of a 
license or it have not been used more than three times). Hereby access to a content item is 
given either via a compliant device of the domain or via a valid person id. This will be 

10 illustrated in greater detail in connection with Figure 4b. 

Figure 3 schematically illustrate the elements of a Domain Devices Certificate 
(DDC) and of a Domain Users Certificate (DUC). As shown, the Domain Devices Certificate 
(DDC) comprises a listing of unique identifiers (DeviDl, Dev.ED2, ...) for one or more 
devices belonging to a given domain, i.e. being authorized devices in the domain. In a 

15 preferred embodiment, the device identifier for a given device, e.g. Dev.IDl, is an (un- 
changeable at least by users) serial or ID number, etc. The given domain is specified by the 
value of the Domain ID, which e.g. may be an 8 byte random identifier. 

Certificates according to the present invention (DDC, DUC, etc.) could e.g. be 
implemented by the well-known SPKI authorization certificate. Additionally, one useful 

20 option is to put a DomainJTO in a holder field of such a SPKI certificate implementing the 
DDC, the DUC and/or the DRC. 

The Domain Users Certificate (DUC) comprises a listing of unique identifiers 
(PersJDl, PersJGD2, . . .) for one or more users/persons belonging to the given domain, i.e. 
being authorized users in the domain. The given domain that the listed users are authorized 

25 within is specified by the value of the Domain ID like described above for the Domain 
Devices Certificate (DDC). A Domain Users Certificate (DUC) and a Domain Devices 
Certificate (DDC) is linked by having the same value of the Domain ID and thereby defines 
the authorized domain (comprising both devices and users). 

Figure 4a illustrates an exemplary (partial) data structure of a content 

30 container, a content right (CR) and a user right certificate (URC) according to the 

embodiment of the present invention shown in Figure 1. Shown is a content container (501) 
which contains protected data/content e.g. obtained from a Service Provider. The content 
container further comprises a content identifier (Cont_ID) unique for the particular content 
item embedded in the content container. In this way, the content identifier (Cont_ID) is used 
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to locate a given content item of the domain, e.g. by searching every content container 
belonging to the specific domain for a matching ContJD. 

Also shown is a content right (CR) (502) comprising a content identifier 
(ConMD) and a content encryption key (Cont Encr K). The content identifier is used to 
5 establish a link to the encrypted content item (in a content container) that the content 

encryption key is for, i.e. the content that the key is needed to de-crypt and thereby enable 
access to. In this particular embodiment, the encryption key is a symmetrical key, i.e. the 
same key is used to both encrypt and decrypt data. Alternatively, other secure schemes may 
be used. 

1 0 Further shown is a user right (UR) or User Right Certificate (URC) (503). The 

URC comprises a content identifier (ContJDD) used for linking a specific content item (and 
content right) with a specific URC. The URC also comprises a person/user identifier 
(PersJD) that indicates which person the specific content is bound to. The person/user 
identifier could e.g. be an ID or serial number for a given person, a name, a hash value of a 

15 public key of the user or in general any unique identifier of a person. 

Further, the URC comprises rights data (Rghts Dat) that define what the given 
user (as identified by the Pers_ID) is allowed to do in relation with the specific content item 
(contained in the content container comprising the same ContJD). These rights data may e.g. 
specify play rights (e.g. restricted to viewers 18 years or older, or European market only, 

20 etc.), one-generation copy rights, a validity period, not used more than three times etc. 
Further, the rights data (Rghts Dat) may also define what all users are allowed to do in 
relation with the specific content item (which may be the same or different than the rights of 
the person identified by Pers_ID). 

As an example, the well-known SPKI authorization certificate could be used 

25 to implement such a URC. 

In the embodiment, where content is linked via devices to the domain in stead 
of via persons, no URC would be needed, but a Device Right Certificate, that would be the 
same as the URC except that it contains a Device ID instead of a Person ID. 

To illustrate the use of a content container, a content right (CR) and a user 

30 right certificate (URC) according to this embodiment of the present invention consider the 
following simple example illustrating access to a content item by a user. 

The content identifier (ContJD) for the given content item that the user wants 
to access and the person identifier (Pers_ID) of the user are obtained. The person identifier 
may e.g. be obtained on the basis of a personalized identification device (e.g. a smart card, 
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mobile phone, a mobile phone containing a smartcard, a biometric sensor, etc. or in another 
way). The content identifier may e.g. be obtained on the basis of a file name, the selection of 
a file, from a header of the content container, etc. 

It is checked if the content item and the user belong to the (same) Authorized 
5 Domain. Checking whether a user belongs to a domain is done by checking if the person 
identifier (PersJD) is comprised in a Domain Users Certificate (DUC) (shown in Figures 1, 
2 and 3). If so, then it has been verified that the user is part of the domain and is allowed to 
access content also being a part of the same domain. 

Then it is checked whether the given content item also belongs to the same 
10 domain, by checking if the content identifier of the content item is bound to a person bound 
to the same domain, i.e. by checking whether there exist a URC bound to the domain that 
comprises the same content identifier. If so, then the content item belongs to the same 
domain and the user (given that the user and/or the device that is used have been verified) 
therefore has the right to access it. Further, the rights data (Rghts Dat) of the URC may also 
15 specify a restricted access to the content item. The rights data may specify rules, rights, 

conditions for the person identified with Pers_ID and/or rules, rights, conditions in general. 
For example, it could specify that that every user in the domain has play rights while the user 
linked via PersJD in addition has exclusive first generation copy rights. 

Usually, the user will obtain access to the content item using a specific device. 
20 If the user is not part of the domain or no valid user ID can be obtained (e.g. because it is a 
friend accessing the content), then it has to be checked whether the specific device that the 
user is using to access the content item is part of the same domain as the content item in order 
to allow the user to access the content item, since he is not (or it can not be established that 
he is) part of the same domain as the content item. This is done by obtaining the DomainJQD 
25 of the DUC that the content item (via a person) was bound to. This Domain_JD is used to 

determine a Domain Devices Certificate (DDC) (shown in Figures 1, 2 and 3) comprising the 
same Domain_ID and checking if the DDC comprises a Dev. ID for the specific device that 
the user is trying to use to access the content item. If the DDC comprises a Dev. ID for the 
specific device then the user (and all other users) may use the specific device to access the 
30 specific content (and all other content of that domain). 

These three steps of validating access to the content item, the user and the 
device may alternatively be done in another order than the one described and e.g. also in 
parallel at least to a certain extent. 
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After it has been verified that the user or the device is part of the same domain 
as the content, then the obtained content identifier is used to locate the content right (CR) of 
the specific content item being accessed in order to obtain the cryptographic key that has to 
be used to decrypt the encrypted content item. Further, the content container comprising the 

5 encrypted content item is also located using the content identifier. 

Finally, the key in the content right is used to decrypt the content item which 
is now accessible, e.g. for rendering, copying on an optical disk, editing, etc. Alternatively, 
the content item may also be decrypted using the content right before sending it to the device 
for access, whereby only the content item needs to be transmitted. However, this requires 

10 special measures in order to protect the content item during transfer so that it is not possible 
to 'leak' the unprotected content. 

This process is illustrated in Figure 4a by the arrows linking the Cont_ID of 
the various structures. 

In this way, if a specific user that has been verified as belonging to the same 

15 domain as the content item being accessed then there is, as mentioned, no need for checking 
whether the device he is using also belongs to the same domain. Further, the validated user 
may access the specific content item using all devices. Likewise, if a specific device has been 
verified as belonging to the same domain, then all users may access the specific content item 
using that specific device and there is no need to verify the user. 

20 Therefore, enhanced flexibility for one or more users when accessing content 

in an AD is obtained while security of the content is still maintaining. 

Figure 4b illustrates an exemplary (partial) data structure of a content 
container, a content right (CR) and a Domain Rights Certificate (DRC) according to the 
embodiment of the present invention shown in Figure 2. In this embodiment, content items 

25 are bound to the domain via a DRC and not to users (via a URC) of the domain. Shown is a 
content container (501) and a content right (CR) (502) that corresponds to the one shown and 
explained e.g. in connection with Figure 4a. 

Further shown is a Domain Rights Certificate (504) that comprises a content 
identifier (Cont_ID) used for linking a specific content item (and content right) with a 

30 specific DRC. The DRC also comprises a domain identifier (DomainJD) that indicates 

which domain the specific content is bound to. The domain identifier corresponds to the one 
in the Domain Devices Certificate (DDC) and the Domain Users Certificate (DUC) explained 
in connection with Figures 1, 2 and 3. 
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Further, the DRC (504) comprises rights data (Rghts Dat) that define what a or 
more users are allowed to do in relation with the specific content item (contained in the 
content container comprising the same Cont_ID). These rights data correspond to the rights 
data of the URC explained in connection with Figure 4a. 

5 To illustrate the use of a content container, a content right and a domain rights 

certificate according to this embodiment of the present invention consider the following 
simple example illustrating access on a specific device to a content item by a user. 

The content identifier (ContJDD) for the given content item that the user wants 
to access, the person identifier (Pers JD) of the user and the domain identifier (Domain_ID) 

10 of the domain containing the content item are obtained. The content identifier and the person 
identifier may be obtained as described in connection with Figure 4a. The domain identifier 
(Domain_ID) is obtained from the DomainJTO of the DRC that the content is bound to. 

It is checked if the content item and the user belong to the (same) Authorized 
Domain. Checking whether a user belongs to a domain is done by checking if the person 

15 identifier (PersJD) is comprised in a Domain Users Certificate (DUC) (as shown in Figures 
1, 2 and 3) having the specific domain identifier. If so, then it has been verified that the user 
is part of the domain and is allowed to access content also being a part of the same domain. 

Then it is checked whether the given content item also belongs to the same 
domain, by checking if the content identifier of the content item is bound to the same domain, 

20 i.e. by checking whether there exist a DRC bound to the domain that comprises the same 

content identifier. If so, then the content item belongs to the same domain and the user (given 
that the user and/or the device that is used have been verified) therefore has the right to 
access it Further, the rights data (Rghts Dat) of the DRC may also specify a restricted access 
to the content item, as described in connection with Figure 4a. 

25 Usually, the user will obtain access to the content item using a specific device. 

If the user is not part of the domain or no valid user ID can be obtained (e.g. because it is a 
friend accessing the content), then it has to be checked whether the specific device that the 
user is using to access the content item is part of the same domain as the content item in order 
to allow the user to access the content item, since he is not (or it can be be established that he 

30 is) part of the same domain. This is done by obtaining the Domain _ID of the DRC that the 
content was bound to. This Domain_ID is used to determine a Domain Devices Certificate 
(DDC) (shown in Figures 1, 2 and 3) comprising the same DomainJ© and checking if the 
DDC comprises a Dev. ID for the specific device that the user is trying to use to access the 
content item. If the DDC comprises a Dev. ID for the specific device then the user (and all 
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other users) may use the specific device to access the specific content (and all other content 
of that domain). 

These three steps of validating access to the content item, the user and the 
device may alternatively be done in another order than the one described and e.g. also in 

5 parallel at least to a certain extent. 

After it has been verified that the user, the content and the device is part of the 
same domain, then the content item is accessed as described in connection with Figure 4a, i.e. 
obtaining the content right and decrypting the content, etc. 

This process is illustrated in Figure 4b by the arrows linking the ContJD of 

10 the various structures. 

Figure 5 schematically illustrate an exemplary system comprising devices and 
persons forming an authorized domain (AD). Shown is network (101) that enables 
communication between a number of devices e.g. in a household. Devices in the example is a 
television set (504), a digital video system (503), a music set (502) and a portable device 

1 5 (507) that is in wireless communication with the network (101) via a wireless access point 
(506). Further shown is a user/person (505). 

In one exemplary scenario, an Authorized Domain (100) has the television set 
(504), the digital video (503), the music set (502) and the user (505) bound to it in addition to 
a number of content items (not shown) (bound according to Fig.l via persons/users or via 

20 devices or bound according to Fig. 1 via Domain Rights Certificate). 

In this scenario, the user wants to access a given content item on the portable 
device (507). He may be located the same place as the devices or at another place (e.g. in a 
hotel room). For a user to obtain access to the content item according to the invention, it has 
to be checked that the person (505) belongs to the domain (100) since the portable device 

25 (507) does not. This may be done by uniquely identifying the user e.g. using a smart card 
reader, e.g. in the portable device (507), which then may transfer the User ID to the network 
(101). The content right and the content item is assumed to be on the portable device (507) 
(otherwise it may be transmitted there). The user is then checked as described in connection 
with Figures 4a or 4b. After validation of the user, then the content item may be accessed it. 

30 In another exemplary scenario, an Authorized Domain (100) has the television 

set (504), the digital video (503), the music set (502) and the portable device (507) bound to 
it in addition to a number of content items (not shown) (bound according to Fig.l via 
persons/users or via devices or bound according to Fig. 1 via Domain Rights Certificate). The 
user (505) is in this scenario not bound to the Authorized Domain (100) as he e.g. may be a 
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neighbor or friend visiting. In this scenario, the user also wants to access a given content item 
on the portable device (507). 

For a user to obtain access to the content item according to the invention, it 
has to be checked that the portable device (507) belongs to the domain (100) since the person 
5 (505) does not. 

This may be done by checking if the portable device (507) is bound to the 
same domain as the content item as described in connection with Figures 4a or 4b. After 
validation of the device, then the content item may be accessed by the user on the portable 
device (507). 

10 In the claims, any reference signs placed between parentheses shall not be 

constructed as limiting the claim. The word "comprising" does not exclude the presence of 
elements or steps other than those listed in a claim. The word "a" or "an" preceding an 
element does not exclude the presence of a plurality of such elements. 

The invention can be implemented by means of hardware comprising several 

15 distinct elements, and by means of a suitably programmed computer. In the device claim 
enumerating several means, several of these means can be embodied by one and the same 
item of hardware. The mere fact that certain measures are recited in mutually different 
dependent claims does not indicate that a combination of these measures cannot be used to 
advantage. 



